8 вересня 2025 р.Українська

Дізнайтеся про тунелювання подій у React Portals. Зрозумійте, як події поширюються деревом компонентів React, незалежно від структури DOM, для створення надійних вебдодатків.

Тунелювання подій у React Portals: глибоке поширення для надійних UI

У світі фронтенд-розробки, що постійно розвивається, React продовжує надавати розробникам по всьому світу можливості для створення складних та високоінтерактивних користувацьких інтерфейсів. Потужна функція в React, портали (Portals), дозволяє нам рендерити дочірні елементи в DOM-вузол, що існує поза ієрархією батьківського компонента. Ця можливість є безцінною для створення елементів UI, таких як модальні вікна, підказки та сповіщення, яким потрібно вирватися за межі стилів батьківського елемента, обмежень z-index або проблем з макетом. Однак, як виявляють розробники від Токіо до Торонто та від Сан-Паулу до Сіднея, використання порталів часто ставить ключове питання: як події поширюються через компоненти, відрендерені таким відокремленим чином?

Цей вичерпний посібник глибоко занурюється у захопливий світ тунелювання подій у React Portals. Ми розвіємо міфи про те, як синтетична система подій React ретельно забезпечує надійне та передбачуване поширення подій, навіть коли ваші компоненти, здається, кидають виклик традиційній ієрархії Document Object Model (DOM). Розуміючи основний механізм "тунелювання", ви отримаєте досвід для створення більш стійких та легких у підтримці застосунків, безшовно інтегруючи портали без несподіваної поведінки подій. Ці знання є вирішальними для забезпечення послідовного та передбачуваного користувацького досвіду для різноманітних глобальних аудиторій та пристроїв.

Розуміння React Portals: міст до відокремленого DOM

За своєю суттю, React Portal надає спосіб відрендерити дочірній компонент у DOM-вузол, що знаходиться поза DOM-ієрархією компонента, який його логічно рендерить. Це досягається за допомогою ReactDOM.createPortal(child, container). Параметр child — це будь-який дочірній елемент React, що можна відрендерити (наприклад, елемент, рядок або фрагмент), а container — це DOM-елемент, зазвичай створений за допомогою document.createElement() та доданий до document.body, або існуючий елемент, такий як document.getElementById('some-global-root').

Основна мотивація використання порталів походить від обмежень стилізації та макету. Коли дочірній компонент рендериться безпосередньо всередині свого батька, він успадковує CSS-властивості батька, такі як overflow: hidden, контексти стекування z-index та обмеження макета. Для певних елементів UI це може бути проблематично.

Навіщо використовувати React Portals? Поширені глобальні сценарії використання:

Модальні та діалогові вікна: Зазвичай вони мають знаходитись на найвищому рівні DOM, щоб гарантувати, що вони з'являються над усім іншим контентом, не зазнаючи впливу CSS-правил батьківських елементів, таких як `overflow: hidden` або `z-index`. Це надзвичайно важливо для послідовного користувацького досвіду, незалежно від того, чи знаходиться користувач у Берліні, Бангалорі чи Буенос-Айресі.
Підказки та поповери: Подібно до модальних вікон, їм часто потрібно виходити за межі контекстів обрізання або позиціонування своїх батьків, щоб забезпечити повну видимість та правильне розміщення відносно viewport. Уявіть, що підказка обрізається, тому що її батьківський елемент має `overflow: hidden` – портали вирішують цю проблему.
Сповіщення та тости: Повідомлення для всього застосунку, які мають з'являтися послідовно, незалежно від того, де в дереві компонентів вони були викликані. Вони надають критично важливий зворотний зв'язок користувачам по всьому світу, часто ненав'язливим способом.
Контекстні меню: Меню, що з'являються після правого кліку, або кастомні контекстні меню, які мають рендеритися відносно курсора миші та виходити за межі обмежень предків, підтримуючи природний потік взаємодії для всіх користувачів.

Розглянемо простий приклад:

            
// index.html
<!DOCTYPE html>
<html lang="en">
  <head>
    <title>React Portal Example</title>
  </head>
  <body>
    <div id="root"></div>
    <div id="modal-root"></div> <!-- This is our Portal target -->
    <script src="index.js"></script>
  </body>
</html>

// App.js (simplified for clarity)
import React from 'react';
import ReactDOM from 'react-dom';

function App() {
  const [showModal, setShowModal] = React.useState(false);

  return (
    <div style={{ border: '2px solid red', padding: '20px' }}>
      <h1>Main Application Content</h1>
      <p>This content resides in the #root div.</p>
      <button onClick={() => setShowModal(true)}>Show Modal</button>
      {showModal && <Modal onClose={() => setShowModal(false)} />}
    </div>
  );
}

function Modal({ onClose }) {
  return ReactDOM.createPortal(
    <div style={{
      position: 'fixed',
      top: 0, left: 0, right: 0, bottom: 0,
      backgroundColor: 'rgba(0, 0, 0, 0.5)',
      display: 'flex', alignItems: 'center', justifyContent: 'center'
    }}>
      <div style={{ backgroundColor: 'white', padding: '30px', borderRadius: '8px' }}>
        <h2>Hello from a Portal!</h2>
        <p>This content is rendered in '#modal-root', not inside '#root'.</p>
        <button onClick={onClose}>Close Modal</button>
      </div>
    </div>,
    document.getElementById('modal-root') // The second argument: the target DOM node
  );
}

ReactDOM.render(<App />, document.getElementById('root'));

У цьому прикладі компонент Modal є логічно дочірнім для App у дереві компонентів React. Однак його DOM-елементи рендеряться всередині div з id #modal-root у файлі index.html, повністю окремо від div #root, де знаходяться App та його нащадки (наприклад, кнопка "Show Modal"). Ця структурна незалежність є ключем до його потужності.

Система подій React: короткий огляд синтетичних подій та делегування

Перш ніж занурюватися в особливості порталів, важливо добре розуміти, як React обробляє події. На відміну від прямого прикріплення нативних обробників подій браузера, React використовує складну систему синтетичних подій з кількох причин:

Кросбраузерна сумісність: Нативні події браузера можуть поводитися по-різному в різних браузерах, що призводить до розбіжностей. Об'єкти SyntheticEvent у React обгортають нативні події браузера, забезпечуючи нормалізований, послідовний інтерфейс та поведінку у всіх підтримуваних браузерах, гарантуючи, що ваш застосунок працюватиме передбачувано від пристрою в Нью-Йорку до Нью-Делі.
Продуктивність та ефективність використання пам'яті (Делегування подій): React не прикріплює обробник подій до кожного окремого DOM-елемента. Замість цього він зазвичай прикріплює один (або кілька) обробників подій до кореня вашого застосунку (наприклад, до об'єкта `document` або основного контейнера React). Коли нативна подія спливає вгору по дереву DOM до цього кореня, делегований обробник React її перехоплює. Ця техніка, відома як делегування подій, значно зменшує споживання пам'яті та покращує продуктивність, особливо в застосунках з великою кількістю інтерактивних елементів або динамічно доданими/видаленими компонентами.
Пулінг подій: Об'єкти SyntheticEvent об'єднуються в пул і використовуються повторно для підвищення продуктивності. Це означає, що властивості об'єкта SyntheticEvent дійсні лише під час виконання обробника подій. Якщо вам потрібно зберегти властивості події асинхронно, ви повинні викликати `e.persist()` або витягти необхідні властивості.

Фази подій: захоплення (тунелювання) та спливання

Події браузера, а отже, і синтетичні події React, проходять через дві основні фази:

Фаза захоплення (або фаза тунелювання): Подія починається з window, спускається вниз по дереву DOM (або дереву компонентів React) до цільового елемента. Обробники, зареєстровані з `useCapture: true` у нативних DOM API, або специфічні для React `onClickCapture`, `onMouseDownCapture` тощо, спрацьовують під час цієї фази. Ця фаза дозволяє елементам-предкам перехопити подію до того, як вона досягне своєї цілі.
Фаза спливання: Після досягнення цільового елемента подія спливає вгору від цільового елемента назад до window. Більшість стандартних обробників подій (наприклад, `onClick`, `onMouseDown` у React) спрацьовують під час цієї фази, дозволяючи батьківським елементам реагувати на події, що виникають у їхніх дочірніх елементах.

Керування поширенням подій:

e.stopPropagation(): Цей метод запобігає подальшому поширенню події як у фазі захоплення, так і у фазі спливання в системі синтетичних подій React. У нативному DOM він запобігає поширенню поточної події вгору (спливання) або вниз (захоплення) по дереву DOM. Це потужний інструмент, але його слід використовувати розсудливо.
e.preventDefault(): Цей метод зупиняє дію за замовчуванням, пов'язану з подією (наприклад, запобігає відправці форми, переходу за посиланням або перемиканню прапорця). Однак він не зупиняє поширення події.

"Парадокс" порталів: DOM проти дерева React

Основна концепція, яку потрібно зрозуміти, працюючи з порталами та подіями, — це фундаментальна відмінність між деревом компонентів React (логічна ієрархія) та ієрархією DOM (фізична структура). Для переважної більшості компонентів React ці дві ієрархії ідеально збігаються. Дочірній компонент, визначений у React, також рендерить свої відповідні DOM-елементи як дочірні елементи DOM-елементів свого батька.

З порталами ця гармонійна відповідність порушується:

Логічна ієрархія (дерево React): Компонент, відрендерений через портал, все ще вважається дочірнім для компонента, який його відрендерив. Цей логічний зв'язок "батько-дитина" є вирішальним для поширення контексту, управління станом (наприклад, `useState`, `useReducer`) і, що найважливіше, для того, як React керує своєю системою синтетичних подій.
Фізична ієрархія (дерево DOM): DOM-елементи, згенеровані порталом, існують у зовсім іншій частині дерева DOM. Вони є сиблінгами або навіть далекими родичами DOM-елементів свого логічного батька, потенційно далеко від місця їх початкового рендерингу.

Це роз'єднання є джерелом як величезної потужності порталів (що дозволяє створювати раніше складні макети UI), так і початкової плутанини щодо обробки подій. Якщо структура DOM відрізняється, як події можуть поширюватися до логічного батька, який не є його фізичним предком у DOM?

Поширення подій з порталами: пояснення механізму "тунелювання"

Саме тут по-справжньому проявляється елегантність та далекоглядність системи синтетичних подій React. React гарантує, що події від компонентів, відрендерених у порталі, все ще поширюються через дерево компонентів React, зберігаючи логічну ієрархію, незалежно від їхнього фізичного положення в DOM. Цей геніальний процес ми називаємо "тунелюванням подій".

Уявіть подію, що виникає на кнопці всередині порталу. Ось послідовність подій, концептуально:

Спрацьовує нативна DOM подія: Клік спочатку викликає нативну подію браузера на кнопці в її фактичному місці в DOM (наприклад, всередині div #modal-root).
Нативна подія спливає до кореня документа: Ця нативна подія потім спливає вгору по фактичній ієрархії DOM (від кнопки, через #modal-root, до `document.body`, і нарешті до самого кореня `document`). Це стандартна поведінка браузера.
Делегований обробник React перехоплює подію: Делегований обробник подій React (зазвичай прикріплений на рівні `document`) перехоплює цю нативну подію.
React відправляє синтетичну подію - логічна фаза захоплення/тунелювання: Замість негайної обробки події на фізичній цілі в DOM, система подій React спочатку визначає логічний шлях від *кореня застосунку React вниз до компонента, який відрендерив портал*. Потім вона симулює фазу захоплення (тунелювання вниз) через усі проміжні компоненти React у цьому логічному дереві. Це відбувається, навіть якщо їхні відповідні DOM-елементи не є прямими предками фізичного розташування порталу в DOM. Будь-які `onClickCapture` або подібні обробники захоплення на цих логічних предках спрацюють у очікуваному порядку. Уявіть це як повідомлення, що надсилається через заздалегідь визначений логічний мережевий шлях, незалежно від того, де прокладені фізичні кабелі.
Виконується обробник цільової події: Подія досягає свого початкового цільового компонента в порталі, і його специфічний обробник (наприклад, `onClick` на кнопці) виконується.
React відправляє синтетичну подію - логічна фаза спливання: Після обробника цілі подія поширюється вгору по логічному дереву компонентів React, від компонента, відрендереного всередині порталу, через батька порталу, і далі вгору до кореня застосунку React. Стандартні обробники спливання, такі як `onClick` на цих логічних предках, спрацюють.

По суті, система подій React блискуче абстрагує фізичні розбіжності DOM для своїх синтетичних подій. Вона розглядає портал так, ніби його дочірні елементи були відрендерені безпосередньо в піддереві DOM батька для цілей поширення подій. Подія "тунелюється" через логічну ієрархію React, що робить обробку подій з порталами напрочуд інтуїтивною, як тільки цей механізм стає зрозумілим.

Наочний приклад тунелювання:

Повернімося до нашого попереднього прикладу з більш явним логуванням, щоб спостерігати за потоком подій:

            
// App.js
import React from 'react';
import ReactDOM from 'react-dom';

function App() {
  const [showModal, setShowModal] = React.useState(false);

  // These handlers are on the logical parent of the Modal
  const handleAppDivClickCapture = () => console.log('1. App div clicked (CAPTURE)!');
  const handleAppDivClick = () => console.log('5. App div clicked (BUBBLE)!');

  return (
    <div style={{ border: '2px solid red', padding: '20px' }}
         onClickCapture={handleAppDivClickCapture} <!-- Fires during tunneling down -->
         onClick={handleAppDivClick}>               <!-- Fires during bubbling up -->
      <h1>Main Application</h1>
      <button onClick={() => setShowModal(true)}>Show Modal</button>
      {showModal && <Modal onClose={() => setShowModal(false)} />}
    </div>
  );
}

function Modal({ onClose }) {
  const handleModalOverlayClickCapture = () => console.log('2. Modal overlay clicked (CAPTURE)!');
  const handleModalOverlayClick = () => console.log('4. Modal overlay clicked (BUBBLE)!');

  return ReactDOM.createPortal(
    <div style={{
      position: 'fixed', top: 0, left: 0, right: 0, bottom: 0,
      backgroundColor: 'rgba(0, 0, 0, 0.5)',
      display: 'flex', alignItems: 'center', justifyContent: 'center'
    }}
         onClickCapture={handleModalOverlayClickCapture} <!-- Fires during tunneling into Portal -->
         onClick={handleModalOverlayClick}>
      <div style={{ backgroundColor: 'white', padding: '30px', borderRadius: '8px' }}>
        <h2>Hello from a Portal!</h2>
        <p>Click the button below.</p>
        <button onClick={() => { console.log('3. Close Modal button clicked (TARGET)!'); onClose(); }}>Close Modal</button>
      </div>
    </div>,
    document.getElementById('modal-root')
  );
}

ReactDOM.render(<App />, document.getElementById('root'));

Якщо ви натиснете кнопку "Close Modal", очікуваний вивід у консолі буде таким:

1. App div clicked (CAPTURE)! (Спрацьовує, коли подія тунелюється вниз через логічного батька)
2. Modal overlay clicked (CAPTURE)! (Спрацьовує, коли подія тунелюється вниз до кореня порталу)
3. Close Modal button clicked (TARGET)! (Обробник фактичної цілі)
4. Modal overlay clicked (BUBBLE)! (Спрацьовує, коли подія спливає вгору від кореня порталу)
5. App div clicked (BUBBLE)! (Спрацьовує, коли подія спливає вгору до логічного батька)

Ця послідовність чітко демонструє, що хоча "Modal overlay" фізично відрендерений у #modal-root, а "App div" — у #root, система подій React все одно змушує їх взаємодіяти так, ніби "Modal" був прямим дочірнім елементом "App" у DOM для цілей поширення подій. Ця послідовність є наріжним каменем моделі подій React.

Глибоке занурення у захоплення подій (справжня фаза тунелювання)

Фаза захоплення є особливо актуальною та потужною для розуміння поширення подій у порталах. Коли подія відбувається на елементі, відрендереному в порталі, система синтетичних подій React фактично "вдає", що вміст порталу глибоко вкладений у його логічного батька для цілей потоку подій. Тому фаза захоплення пройде вниз по дереву компонентів React від кореня, через логічного батька порталу (компонент, який викликав `createPortal`), а *потім* у вміст порталу.

Цей аспект "тунелювання вниз" означає, що будь-який логічний предок порталу може перехопити подію *до того*, як вона досягне вмісту порталу. Це критично важлива можливість для реалізації таких функцій, як:

Глобальні гарячі клавіші/шорткати: Компонент вищого порядку або обробник на рівні `document` (через `useEffect` у React з `onClickCapture`) може виявляти події клавіатури або кліки до того, як вони будуть оброблені глибоко вкладеним порталом, що дозволяє здійснювати глобальне керування застосунком.
Керування оверлеями: Компонент, що (логічно) обгортає портал, може використовувати `onClickCapture` для виявлення будь-якого кліку, що проходить через його логічний простір, незалежно від фізичного розташування порталу в DOM, що дозволяє реалізувати складну логіку закриття оверлеїв.
Запобігання взаємодії: У рідкісних випадках предку може знадобитися запобігти попаданню події у вміст порталу, можливо, як частина тимчасового блокування UI або умовного шару взаємодії.

Розглянемо обробник кліку на `document.body` проти `onClickCapture` у React на логічному батькові порталу:

            
// App.js
import React from 'react';
import ReactDOM from 'react-dom';

function App() {
  const [showNotification, setShowNotification] = React.useState(false);

  React.useEffect(() => {
    // Native document click listener: respects physical DOM hierarchy
    const handleNativeDocumentClick = () => {
      console.log('--- NATIVE: Document click detected. (Fires first, based on DOM position) ---');
    };
    document.addEventListener('click', handleNativeDocumentClick);
    return () => document.removeEventListener('click', handleNativeDocumentClick);
  }, []);

  const handleAppDivClickCapture = () => console.log('1. APP: CAPTURE event (React Synthetic - logical parent)');

  return (
    <div onClickCapture={handleAppDivClickCapture}>
      <h2>Main App</h2>
      <button onClick={() => setShowNotification(true)}>Show Notification</button>
      {showNotification && <Notification />}
    </div>
  );
}

function Notification() {
  const handleNotificationDivClickCapture = () => console.log('2. NOTIFICATION: CAPTURE event (React Synthetic - Portal root)');

  return ReactDOM.createPortal(
    <div style={{ border: '1px solid blue', padding: '10px' }}
         onClickCapture={handleNotificationDivClickCapture}>
      <p>A message from a Portal.</p>
      <button onClick={() => console.log('3. NOTIFICATION BUTTON: Clicked (TARGET)!')}>OK</button>
    </div>,
    document.getElementById('notification-root') // Another root in index.html, e.g., <div id="notification-root"></div>
  );
}

ReactDOM.render(<App />, document.getElementById('root'));

Якщо ви натиснете кнопку "OK" всередині порталу Notification, вивід у консолі може виглядати так:

--- NATIVE: Document click detected. (Fires first, based on DOM position) --- (Це спрацьовує від `document.addEventListener`, який враховує нативний DOM, тому браузер обробляє його першим.)
1. APP: CAPTURE event (React Synthetic - logical parent) (Система синтетичних подій React починає свій логічний шлях тунелювання з компонента `App`.)
2. NOTIFICATION: CAPTURE event (React Synthetic - Portal root) (Тунелювання продовжується до кореня вмісту порталу.)
3. NOTIFICATION BUTTON: Clicked (TARGET)! (Спрацьовує обробник `onClick` цільового елемента.)
(Якби на Notification div або App div були обробники спливання, вони б спрацювали наступними у зворотному порядку.)

Ця послідовність яскраво ілюструє, що система подій React надає пріоритет логічній ієрархії компонентів як для фази захоплення, так і для фази спливання, забезпечуючи послідовну модель подій у вашому застосунку, відмінну від сирих нативних подій DOM. Розуміння цієї взаємодії є життєво важливим для налагодження та проєктування надійних потоків подій.

Практичні сценарії та корисні поради

Сценарій 1: Глобальна логіка "кліку ззовні" для модальних вікон

Поширеною вимогою для модальних вікон, що має вирішальне значення для гарного користувацького досвіду в усіх культурах та регіонах, є їх закриття, коли користувач клацає де-небудь за межами основної області вмісту модального вікна. Без розуміння тунелювання подій у порталах це може бути складно. Надійний, "React-ідіоматичний" спосіб використовує тунелювання подій та `stopPropagation()`.

            
function AppWithModal() {
  const [isOpen, setIsOpen] = React.useState(false);
  const modalRef = React.useRef(null);

  // This handler will fire for any click *logically* within the App,
  // including clicks that tunnel up from the Modal, if not stopped.
  const handleAppClick = () => {
    console.log('App received a click (BUBBLE).');
    // If a click outside modal content but on the overlay should close the modal,
    // and that overlay's onClick handler closes the modal, then this App handler
    // might only fire if the event bubbles past the overlay or if the modal is not open.
  };

  const handleCloseModal = () => setIsOpen(false);

  return (
    <div onClick={handleAppClick}>
      <h2>App Content</h2>
      <button onClick={() => setIsOpen(true)}>Open Modal</button>
      {isOpen && <ClickOutsideModal onClose={handleCloseModal} />}
    </div>
  );
}

function ClickOutsideModal({ onClose }) {
  // This outer div of the portal acts as the semi-transparent overlay.
  // Its onClick handler will close the modal ONLY if the click has bubbled up to it,
  // meaning it did NOT originate from the inner modal content AND was not stopped.
  return ReactDOM.createPortal(
    <div style={{
      position: 'fixed', top: 0, left: 0, right: 0, bottom: 0,
      backgroundColor: 'rgba(0,0,0,0.6)',
      display: 'flex', alignItems: 'center', justifyContent: 'center'
    }}
    onClick={onClose} > <!-- This handler will close the modal if clicked outside inner content -->
      <div style={{
        backgroundColor: 'white', padding: '25px', borderRadius: '10px',
        minWidth: '300px', maxWidth: '80%'
      }}
      // Crucially, stop propagation here to prevent the click from bubbling up
      // to the overlay's onClick handler, and thus to App's onClick handler.
      onClick={(e) => e.stopPropagation()} >
        <h3>Click Me Or Outside!</h3>
        <p>Click anywhere outside this white box to close the modal.</p>
        <button onClick={onClose}>Close with Button</button>
      </div>
    </div>,
    document.getElementById('modal-root')
  );
}

У цьому надійному прикладі: коли користувач клацає *всередині* білого блоку вмісту модального вікна, `e.stopPropagation()` на внутрішньому `div` запобігає спливанню цієї синтетичної події кліку до обробника `onClick={onClose}` напівпрозорого оверлею. Завдяки тунелюванню в React, це також запобігає спливанню події далі до `onClick={handleAppClick}` у `AppWithModal`. Якщо користувач клацає *за межами* білого блоку вмісту, але все ще *на* напівпрозорому оверлеї, спрацює обробник `onClick={onClose}` оверлею, закриваючи модальне вікно. Цей патерн забезпечує інтуїтивну поведінку для користувачів, незалежно від їхнього рівня підготовки чи звичок взаємодії.

Сценарій 2: Запобігання спрацьовуванню обробників предків на події з порталів

Іноді у вас є глобальний обробник подій (наприклад, для логування, аналітики або загальносистемних гарячих клавіш) на компоненті-предку, і ви хочете запобігти спрацьовуванню його на події, що виникають у дочірньому порталі. Саме тут розумне використання `e.stopPropagation()` у вмісті порталу стає життєво важливим для чистих та передбачуваних потоків подій.

            
function AnalyticsApp() {
  const [showPanel, setShowPanel] = React.useState(false);

  const handleGlobalClick = () => {
    console.log('AnalyticsApp: Click detected anywhere in the main app (for analytics/logging).');
  };

  return (
    <div onClick={handleGlobalClick}> <!-- This will log all clicks that bubble up to it -->
      <h2>Main App with Analytics</h2>
      <button onClick={() => setShowPanel(true)}>Open Action Panel</button>
      {showPanel && <ActionPanel onClose={() => setShowPanel(false)} />}
    </div>
  );
}

function ActionPanel({ onClose }) {
  // This Portal renders into a separate DOM node (e.g., <div id="panel-root">).
  // We want clicks *inside* this panel to NOT trigger AnalyticsApp's global handler.
  return ReactDOM.createPortal(
    <div style={{ border: '1px solid darkgreen', padding: '15px', backgroundColor: '#f0f0f0' }}
         onClick={(e) => e.stopPropagation()} > <!-- Crucial for stopping logical propagation -->
      <h3>Perform Action</h3>
      <p>This interaction should be isolated.</p>
      <button onClick={() => { console.log('Action performed!'); onClose(); }}>Submit</button>
      <button onClick={onClose}>Cancel</button>
    </div>,
    document.getElementById('panel-root')
  );
}

Розмістивши `onClick={(e) => e.stopPropagation()}` на зовнішньому `div` вмісту порталу `ActionPanel`, будь-яка синтетична подія кліку, що виникає всередині панелі, буде зупинена в цій точці. Вона не буде тунелюватися до `handleGlobalClick` у `AnalyticsApp`, таким чином зберігаючи вашу аналітику або інші глобальні обробники чистими від специфічних для порталу взаємодій. Це дозволяє точно контролювати, які події викликають які логічні дії у вашому застосунку.

Сценарій 3: Context API з порталами

Context надає потужний спосіб передачі даних через дерево компонентів без необхідності передавати пропси вручну на кожному рівні. Поширене занепокоєння полягає в тому, чи працює контекст через портали, враховуючи їхнє відокремлення від DOM. Хороша новина: так, працює! Оскільки портали все ще є частиною логічного дерева компонентів React, вони можуть споживати контекст, наданий їхніми логічними предками, що підтверджує ідею, що внутрішні механізми React надають пріоритет дереву компонентів.

            
const ThemeContext = React.createContext('light');

function ThemedApp() {
  const [theme, setTheme] = React.useState('light');

  return (
    <ThemeContext.Provider value={theme}>
      <div style={{ padding: '20px', backgroundColor: theme === 'light' ? '#f8f8f8' : '#333', color: theme === 'light' ? '#333' : '#eee' }}>
        <h2>Themed Application ({theme} mode)</h2>
        <p>This app adapts to user preferences, a global design principle.</p>
        <button onClick={() => setTheme(theme === 'light' ? 'dark' : 'light')}>Toggle Theme</button>
        <ThemedPortalMessage />
      </div>
    </ThemeContext.Provider>
  );
}

function ThemedPortalMessage() {
  // This component, despite rendering in a Portal, still consumes context from its logical parent.
  const theme = React.useContext(ThemeContext);

  return ReactDOM.createPortal(
    <div style={{
      position: 'fixed', top: '20px', right: '20px', padding: '15px', borderRadius: '5px',
      backgroundColor: theme === 'light' ? 'lightblue' : 'darkblue',
      color: 'white',
      boxShadow: '0 2px 10px rgba(0,0,0,0.2)'
    }}>
      <p>This message is themed: <strong>{theme} mode</strong>.</p>
      <small>Rendered outside the main DOM tree, but within the logical React context.</small>
    </div>,
    document.getElementById('notification-root') // Assumes <div id="notification-root"></div> exists in index.html
  );
}

Навіть якщо ThemedPortalMessage рендериться в #notification-root (окремий DOM-вузол), він успішно отримує контекст `theme` від ThemedApp. Це демонструє, що поширення контексту слідує за логічним деревом React, віддзеркалюючи те, як працює поширення подій. Ця послідовність спрощує управління станом для складних UI-компонентів, що використовують портали.

Сценарій 4: Обробка подій у вкладених порталах (просунутий рівень)

Хоча це менш поширено, портали можна вкладати, тобто компонент, відрендерений у порталі, сам рендерить інший портал. Механізм тунелювання подій витончено обробляє ці складні сценарії, розширюючи ті самі принципи:

Подія виникає у вмісті найглибшого порталу.
Вона спливає вгору через компоненти React усередині цього найглибшого порталу.
Потім вона тунелюється до компонента, який *відрендерив* цей найглибший портал.
Звідти вона спливає до наступного логічного батька, який може бути вмістом іншого порталу.
Це триває, доки вона не досягне кореня всього застосунку React.

Ключовий висновок полягає в тому, що логічна ієрархія компонентів React залишається єдиним джерелом істини для поширення подій, незалежно від того, скільки рівнів відокремлення від DOM вводять портали. Ця передбачуваність є надзвичайно важливою для створення високо модульних та розширюваних систем UI.

Найкращі практики та рекомендації для глобальних застосунків

Розсудливе використання e.stopPropagation(): Хоча це потужний інструмент, надмірне використання stopPropagation() може призвести до крихкого коду, який важко налагоджувати. Використовуйте його точно там, де вам потрібно запобігти подальшому поширенню певних подій вгору по логічному дереву, зазвичай у корені вмісту вашого порталу для ізоляції його взаємодій. Розгляньте, чи не є `onClickCapture` на предку кращим підходом для перехоплення, аніж зупинка поширення в джерелі, залежно від вашої конкретної вимоги.
Доступність (A11y) є найважливішою: Портали, особливо для модальних та діалогових вікон, часто створюють значні проблеми з доступністю, які необхідно вирішувати для глобальної, інклюзивної бази користувачів. Переконайтеся, що:
- Керування фокусом: Коли портал (наприклад, модальне вікно) відкривається, фокус має бути програмно переміщений і "замкнений" всередині нього. Користувачі, які навігують за допомогою клавіатури або допоміжних технологій, очікують цього. Після закриття порталу фокус повинен повернутися до елемента, який викликав його відкриття. Для надійної обробки цієї складної поведінки в різних браузерах та на різних пристроях настійно рекомендуються бібліотеки, такі як `react-focus-lock` або `focus-trap-react`.
- Навігація з клавіатури: Переконайтеся, що користувачі можуть взаємодіяти з усіма елементами всередині порталу, використовуючи лише клавіатуру (наприклад, Tab, Shift+Tab для навігації, Esc для закриття модальних вікон). Це є фундаментальним для користувачів з порушеннями моторики або тих, хто просто віддає перевагу взаємодії з клавіатури.
- Ролі та атрибути ARIA: Використовуйте відповідні ролі та атрибути WAI-ARIA. Наприклад, модальне вікно зазвичай повинно мати `role="dialog"` (або `alertdialog`), `aria-modal="true"` та `aria-labelledby` / `aria-describedby` для зв'язку з його заголовком та описом. Це надає важливу семантичну інформацію для скрін-рідерів та інших допоміжних технологій.
- Атрибут `inert`: Для сучасних браузерів розгляньте використання атрибута `inert` на елементах поза активним модальним вікном/порталом, щоб запобігти фокусуванню та взаємодії з фоновим контентом, покращуючи користувацький досвід для користувачів допоміжних технологій.
Блокування прокрутки: Коли відкривається модальне вікно або повноекранний портал, ви часто хочете запобігти прокручуванню фонового вмісту. Це поширений патерн UX і зазвичай включає стилізацію елемента `body` за допомогою `overflow: hidden`. Пам'ятайте про потенційні зсуви макета або проблеми з зникненням смуги прокрутки в різних операційних системах та браузерах, що може вплинути на користувачів по всьому світу. Можуть допомогти бібліотеки, такі як `body-scroll-lock`.
Рендеринг на стороні сервера (SSR): Якщо ви використовуєте SSR, переконайтеся, що елементи-контейнери для ваших порталів (наприклад, `#modal-root`) присутні у вашому початковому HTML-виводі, або обробляйте їх створення на стороні клієнта, щоб запобігти розбіжностям при гідратації та забезпечити плавний початковий рендеринг. Це критично для продуктивності та SEO, особливо в регіонах з повільним інтернет-з'єднанням.
Стратегії тестування: При тестуванні компонентів, що використовують портали, пам'ятайте, що вміст порталу рендериться в іншому DOM-вузлі. Інструменти, такі як `@testing-library/react`, зазвичай достатньо надійні, щоб знайти вміст порталу за його доступною роллю або текстовим вмістом, але іноді вам може знадобитися перевірити `document.body` або конкретний контейнер порталу безпосередньо, щоб підтвердити його присутність або взаємодії. Пишіть тести, які симулюють взаємодію користувача та перевіряють очікуваний потік подій.

Поширені помилки та їх вирішення

Плутанина між ієрархією DOM та React: Як вже неодноразово зазначалося, це найпоширеніша помилка. Завжди пам'ятайте, що для синтетичних подій React логічне дерево компонентів React диктує поширення, а не фізична структура DOM. Намалювавши дерево компонентів, часто можна це прояснити.
Нативні обробники подій проти синтетичних подій React: Будьте надзвичайно уважними, змішуючи нативні обробники подій DOM (наприклад, `document.addEventListener('click', handler)`) з синтетичними подіями React. Нативні обробники завжди будуть враховувати фізичну ієрархію DOM, тоді як події React враховують логічну ієрархію React. Це може призвести до несподіваного порядку виконання, якщо це не зрозуміти, де нативний обробник може спрацювати раніше за синтетичний, або навпаки, залежно від того, де вони прикріплені та фази події.
Надмірне використання `stopPropagation()`: Хоча це необхідно в певних сценаріях, надмірне використання `stopPropagation()` може зробити вашу логіку подій крихкою та важкою для підтримки. Намагайтеся проєктувати взаємодії ваших компонентів так, щоб події природно протікали без необхідності їх примусово зупиняти, вдаючись до `stopPropagation()` лише тоді, коли це суворо необхідно для ізоляції поведінки компонента.
Налагодження обробників подій: Якщо обробник подій не спрацьовує, як очікувалося, або спрацьовує занадто багато обробників, використовуйте інструменти розробника в браузері для перевірки обробників подій. Використання `console.log`, стратегічно розміщених у обробниках вашого компонента React (особливо `onClickCapture` та `onClick`), може бути безцінним для відстеження шляху події як через фазу захоплення, так і через фазу спливання, допомагаючи вам визначити, де подія перехоплюється або зупиняється.
Війни z-index з кількома порталами: Хоча портали допомагають уникнути проблем з z-index батьківських елементів, вони не вирішують глобальних конфліктів z-index, якщо на кореневому рівні документа існує кілька елементів з високим z-index (наприклад, кілька модальних вікон з різних компонентів/бібліотек). Ретельно плануйте свою стратегію z-index для контейнерів ваших порталів, щоб забезпечити правильний порядок накладання у всьому вашому застосунку для послідовної візуальної ієрархії.

Висновок: опанування глибокого поширення подій з React Portals

React Portals є неймовірно потужним інструментом, що дозволяє розробникам долати значні проблеми зі стилізацією та макетом, які виникають через суворі ієрархії DOM. Ключ до розкриття їхнього повного потенціалу, однак, лежить у глибокому розумінні того, як система синтетичних подій React обробляє поширення подій через ці відокремлені структури DOM.

Концепція "тунелювання подій у React Portals" елегантно описує, як React надає пріоритет логічному дереву компонентів для потоку подій. Вона гарантує, що події від елементів, відрендерених у порталі, правильно поширюються вгору через їхніх концептуальних батьків, незалежно від їхнього фізичного розташування в DOM. Використовуючи фазу захоплення (тунелювання вниз) та фазу спливання (спливання вгору) через дерево React, розробники можуть реалізовувати надійні функції, такі як глобальні обробники кліків ззовні, підтримувати контекст та ефективно керувати складними взаємодіями, забезпечуючи передбачуваний та високоякісний користувацький досвід для різноманітних користувачів у будь-якому регіоні.

Прийміть це розуміння, і ви побачите, що портали, далекі від того, щоб бути джерелом складнощів, пов'язаних з подіями, стають природною та інтуїтивною частиною вашого інструментарію React. Це майстерність дозволить вам створювати складні, доступні та продуктивні користувацькі інтерфейси, які витримують випробування складними вимогами UI та глобальними очікуваннями користувачів.